<html>
<head>

<title>Issuezilla Tips and Tricks</title>

</head>
<body>

<span class="Header" nowrap>IssueZilla tips and tricks</span>  
<p>
    <span class="PlainText"><strong>Additional resources about issues: Index</strong>
<ul>
	<dl>
	<dt><a href="ProjectIssues.html">Project Issues help</a>
		<dd><a href="issue_lifecycle.html">The issue life cycle</a> 
		<dd><a href="issuewritinghelp.html">Issue writing guidelines</a>
		<dd><strong>You are here: IssueZilla tips and tricks</strong> 
		<dd><a href="contributing_patches.html">Contributing patches</a>
	<dt><a href="/servlets/HelpTOC">Back to main Help index</a>
	</dl>
</ul>
<hr noshade size=1>
     <p>
Here are a few guidelines to help you effectively make use of issue tracking in your collaborative development projects.

     <ul>

      <li>When you see an issue come through email channels, this is
      an indication that you have either been assigned or cc'd on a
      particular issue. Don't ignore it!

      <p>

	<li>Make frequent use of the "My issues" option in the
	IssueZilla tool bar. This list displays all project issues
	assigned to you.

	<p>

      <li>If you are assigned an issue and you have the bandwith,
      <strong>it is your responsibility to investigate
      the issue</strong>. If it has been given a milestone, is also your
      responsibility to "fix" the issue in the proper order by the
      designated date, <i>or</i> to communicate the reasons for not
      meeting the milestone date using the issue "comments" field.

      <p>

      <li>If you are assigned an issue and you do <i>not</i> have enough time to do the work, it is your responsibility to communicate (through the
      description field) your inability to complete the assignment.

      <p>

      <li>Don't just go and fix issues that have not been given a
      milestone. It is extremely important for the project leader to
      carefully consider the impact the milestone's changes might have
      on the codebase. An issue without a milestone indicates that
      other factors have yet to be determined.

      <p>

      <li>Proceed through your issues in order sorted by milestone,
      then by priority. If it makes sense to modify the sequence
      that's fine, just don't blow the milestone!

      <p>

      <li>When an issue is completed (you've written the code, etc.),
      if applicable check it into CVS and mark the issue "fixed."
      Include a comment on how you did it. Fixed=Checked In!

      <p>

      <li>Try not to batch up a bunch of issue fixes and check them in
      all at once. This wreaks havoc on the project administrator's
      ability to track status and prohibits granular roll backs, etc.

      <p>

      <li>Feel absolutely positively free to add more issues to the
      list as you realize them. <strong>Just be sure
      to query the issue database first to avoid entering duplicate
      issues!</strong>

      <p>

      <li>Post any and all comments/notes pertaining to a particular
      issue using the description field. This way anyone who is
      handling an issue can easily see its history and get to work on it.
      The issue tracker <strong>must</strong>
      reflect all of your changes for project release notes to be
      accurate.

      <p>

      <li>Refer to the issue tracker on an almost constant basis. In
      practice you'll find that this is a very efficient way of seeing
      what is expected of you rather than sifting through emails.

     </ul>
 
<p>
 <hr noshade size=1>
<a href="ProjectIssues.html">Back to Project Issues help</a><br>
<a href="/servlets/HelpTOC">Back to main Help index</a>

</body>
</html>
